\documentclass[a4paper]{article}

\usepackage[dutch]{babel}
\usepackage{multicol}
\usepackage{a4wide}
\usepackage{color}
\usepackage{graphicx}

\setcounter{tocdepth}{2}

\title{Series 1: Voorbereiding voor Series 2 en 3}

\author{Nico Schoenmaker en Menno Middel}

\usepackage[pdfhighlight=/N,colorlinks=true]{hyperref}

\newcommand{\fixme}[1]{\textcolor{red}{\textbf{[fixme!]#1[fixme!]}}}

\begin{document}

\maketitle

\tableofcontents

%\begin{abstract}
%
%\end{abstract}

\section{Opdracht 0: Literature}

	\subsection{Rules and Tools for Software Evolution Planning and
	Management}

		\subsubsection{Waar gaat de paper over}

			De paper beschrijft een verzameling van methodes die het
			onderhoud in de evolutie van de software ondersteund.
			Hiervoor wordt software in een drietal programmatypen
			ingedeeld. Het geeft de wat, de waarom en de hoe van
			software evolution aan.

		\subsubsection{Wat is de structuur van de paper}
		
			De paper begint met een samenvatting en inleiding. Hierna
			worden acht wetten van software evolutie planning ingeleid.
			Dan worden een beschrijving gegeven van de drie
			verschillende typen waarin programma's ingedeeld kunnen
			worden. De acht wetten worden dan in detail beschreven. Elke
			wet is in \'{e}\'{e}n zin samengevat waarna een
			gedetailleerde beschrijving en een lijst met richtlijnen
			volgen. Na de acht regels volgen nog twee uitbreidingen op
			de regels. Als laatst komen de conclusies en
			dankbetuigingen.

		\subsubsection{Welke hoofdstukken zijn niet relevant}

			Van de paper zijn van alle hoofdstukken delen interessant.
			Elk hoofdstuk is namelijk deel van een set regels en
			richtlijnen die belangrijk zijn voor het plannen en managen
			van de software evolutie. 

			De conclusie is minder interessant omdat deze paper een
			methode uitlegt, waarin de conclusie een ondergeschikte
			waarde heeft. Het is meer een afsluitend verhaal over de
			situatie waarin de paper is geschreven. Dit betekend niet
			dat de conclusie geheel irrelevant is. Voor de gene die
			belang heeft in handvatten om software evolutie te plannen,
			zijn de regels en hun uitleg zelf veel belangrijker.
		
		\subsubsection{Detail niveau}

			Van het hoofdstuk waar de wetten worden ingeleid is tabel
			1 het belangrijkste. Deze geeft in \'{e}\'{e}n oogopslag een
			globaal overzicht van de wetten. De rest van het hoofdstuk
			is alleen relevant voor de lezers die ge\"{i}ntresseerd zijn
			in de geschiedenis van de regels

			Van paragraaf 3.1 zijn alinea 2, 3 en 4 belangrijk, omdat zij
			de verschillende typen globaal uitleggen. Van paragraaf 3.2
			zijn de eerste regel van de eerste alinea en de hele tweede
			alinea belangrijk, omdat zij aangeven dat (en waarom) de
			wetten veelal alleen voor E-type systemen gelden.

			Paragraaf 3.3 en 3.4 geven vooral een beschrijving van
			S-type systemen en de relatie tussen de E-type en S-type
			systemen weer. Dit is niet essentie\"{e}l voor het begrip
			van de wetten.

			Van de hoofdstukken waarin de wetten zelf beschreven zijn is
			alleen de eerste zin, de eerste alinea en de opsomming op
			het einde belangrijk. Deze geven een gedetailleerdere
			beschrijving van de wetten en een lijst met richtlijnen voor
			de wet.

		\subsubsection{Take home messages}

			\begin{itemize}

				\item Ook al zijn veel van de aanbevelingen uit de paper
				moeilijk en duur, op langer termijn zijn ze het waard om
				te volgen.

				\item Het bepalen van de evolutie strategie is de
				verantwoordelijkheid van het management.

				\item Soms zitten business en technische beslissingen de
				planning van evolutie tegen.

			\end{itemize}

	\subsection{Software Maintenance and Evolution: a Roadmap}

		\subsubsection{Waar gaat de paper over}

			De paper beschrijft een nieuwe manier voor het cree\"{e}ren en het
			onderhouden van software.

		\subsubsection{Wat is de structuur van de paper}

			De paper begint met het geven van een definitie van software
			onderhoud. Vervolgens wordt het belang van maintenance
			onderstreept. In het tweede hoofdstuk wordt het staged model
			beschreven, een model waarin de complete levenscyclus van software
			wordt beschreven. Het derde hoofdstuk gaat over veranderingen in
			software. Het vierde hoofdstuk gaat over legacy software. Het
			vijfde hoofdstuk beschrijft hoe software evolutie in de toekomst
			anders zal moeten. Daarna volgt er een conclusie en
			bronvermelding.

		\subsubsection{Welke hoofdstukken zijn niet relevant}

			Het eerste hoofdstuk is relevant omdat deze de definitie
			geeft van software onderhoud. Ook het tweede hoofdstuk is
			relevant.  Hierin wordt een nieuw model van de levenscyclus
			van software beschreven.  Het derde hoofdstuk is niet
			relevant, omdat hier eigenlijk de basics van change
			management worden beschreven. Van het vierde hoofdstuk zijn
			sommige stukken relevant, zie hiervoor 'Level of detail'.
			Het vijfde hoofdstuk is wel relevant, omdat deze software
			evolutie in de toekomst beschrijft.

		\subsubsection{Level of detail}

			Van het eerste hoofdstuk kan de eerste paragraaf snel worden
			doorgelezen. De tweede en derde paragraaf zijn vooral relevant.
			Het hele tweede hoofdstuk is ook relevant. Het vierde hoofdstuk
			gaat vooral over de continue verandering in de techniek en legacy
			software, de kern van het hoofdstuk is te vinden in de vijfde
			alinea, en de twee alinea's na de opsomming. Hoofdstuk vijf en de
			conclusie zijn beide relevant.

		\subsubsection{Take home messages}
		
			\begin{itemize}

				\item Tijdens de initi\"{e}le constructie van een programma is het
				het belangrijkste doel om ervoor te zorgen dat de opvolgende
				evolutie makkelijk plaats kan vinden.

				\item Twee belangrijke resultaten van deze eerste versie zijn
				een duidelijke architectuur en de kennis die het programmeer
				team verzameld.

				\item Op het moment is er teveel nadruk op de techniek, in
				plaats van op de eindgebruiker.

				\item Software evolutie moet een belangrijke plaats krijgen in
				het veld van software engineering.

			\end{itemize}

\section{Opdracht 1: Exploring the DidiWiki}

	\subsection{Opdracht 1.1}

		Om deze vraag te beantwoorden gaan we uit van de typen
		onderhoudt die beschreven worden in \cite{roadmap}. Deze lijst
		onderscheid de volgende typen onderhoud:

		\begin{itemize}

			\item Adaptive - changes in the software environment

			\item Perfective - new user requirements

			\item Corrective - fixing errors

			\item Preventive - prevent problems in the future.

		\end{itemize}

		\paragraph{Extend with a ``Google Plugin''}

			Perfective - Het is een nieuwe feature waarbij wij aannemen
			dat hij door gebruikers is ingediend of handig wordt
			gevonden.

		\paragraph{Rewrite as a Apache Httpd module}

			Preventive - Bij het gebruik van Apache is de kans groter
			dat DidiWiki in een veiligere http omgeving
			ge\"{i}mplementeerd is.  Hierdoor is DidiWiki minder
			gevoelig voor exploids, door de constante ontwikkeling die
			Apache ondergaat. Dit voorkomt de genoemde problemen in de
			toekomst.

		\paragraph{Using MarkDown in DidiWiki}

			Perfective - Ook dit is een nieuwe feature, die niet
			essentieel is voor het DidiWiki, omdat deze zelf al een
			markup taal heeft. Dit is puur een toevoeging van gebruikers
			gemak en het inspelen op nieuwe (veelgebruikte) standaarden
			staat hierbij centraal.

		\paragraph{Convert old markup to MarkDown}

			Adaptive - Door MarkDown te ondersteunen veranderd de
			software. De conversie van de oude indeling naar MarkDown
			speelt in op deze verandering.

		\paragraph{Fix "buffer overflow" for security}

			Preventive - Hierbij nemen we aan dat de exploid nog niet
			voor problemen heeft gezorgd, maar mogelijk in de toekomst
			wel. Deze aanname maakt deze wijziging preventive, omdat er
			rekening gehouden wordt met toekomstige problemen. Wanneer
			deze aanname incorrect is, zal dit corrective onderhoud
			zijn. Er wordt dan een defect aan de software gerepareerd.

		\paragraph{Address all the ``Todo's''}

			Preventive en Perfective - De ``Todo's'' hebben afwisselende
			insteek. Veel hebben te maken met veiligheid en
			effici\"{e}ntie. Deze kunnen onder preventive onderhoud
			omdat ze nog geen probleem vormen maar mogelijk in de
			toekomst wel. Verder staan er nieuwe features tussen. Het
			gaat hier om zaken die niet mogelijk zijn in de huidige
			implementatie, maar wel wenselijk zijn. Dit maakt deze
			``Todo's'' perfective.

		\paragraph{Configurable server port}

			Perfective - Dit is nu wel mogelijk in de broncode, maar
			niet voor de eindgebruiker door configuratie. Dit maakt het
			een requirement vanuit de gebruiker, en daarom perfective
			onderhoud.

	\subsection{Opdracht 1.2}

			Om aan te geven waar het onderhoud moet plaatsvinden
			presenteren we een sequence diagram (zie figuur
			\ref{fig:sequence_didiwiki}). Dit diagram geeft de ideale
			doorloop van de applicatie aan waarbij een wiki pagina
			worden opgevraagd bij de server. Hierbij zijn twee punten
			gemarkeerd. 

	\begin{figure*}[hb]
		\centering
		\includegraphics[width=\textwidth]{sequence_didiwiki}
		\caption{Een sequence diagram van het afhandelen van een http
		request die een standaard wiki pagina opent. Hierbij zijn de
		plaatsen waar verandering optreed aangegeven.}
		\label{fig:sequence_didiwiki}
	\end{figure*}

		\paragraph{Punt A}

			geeft de plaats aan waar onderhoud gepleegd moet worden
			wanneer de server port configureerbaar moet worden. In
			plaats dat de variabel port in didi.c statisch wordt
			toegewezen in de code kan deze toewijzing vanuit de
			envirement variable plaatsvinden. De rest van de code kan op
			die manier ongewijzigd blijven. 

		\paragraph{Punt B}

			geeft aan waar het onderhoud plaats vind wanneer MarkDown
			ondersteunt moet worden door DidiWiki. Dit is de plek in de
			code waar de wiki pagina's geparsed worden naar html. Om de
			code overzichtelijk te behouden kan de inhoud van de huidige
			methode het beste in een nieuwe methode gezet worden. Dit
			zal de methode zijn om wiki om te zetten naar html.
			Daarnaast komt nog een nieuwe methode om markdown om te
			zetten naar html. De keuze welke methode gebruikt moet
			worden zal plaats vinden in de huidige
			wiki\_print\_data\_as\_html(). Er zal ook ergens uit de data
			moeten blijken of het wiki of MarkDown data betreft.

\section{Opdracht 2: Evolution of a complex Java Web application:
JspWiki}

	\subsection{Opdracht 2.0}

		\subsubsection{Complexiteit van maintaince}
		
			Het volgende maakt maintaince moeilijk:
		
		\paragraph{Verborgen ontwerp beslissingen}

			Veel ontwerp beslissingen zullen impliciet gemaakt zijn in
			de ontwikkeling van het te analyseren softwareproduct. Deze
			beslissingen zullen veelal niet beschreven zijn in de
			documentatie.

		\paragraph{Missen van documentatie}

			In veel legacy software is geen documentatie aanwezig naast
			de broncode zelf en het commentaar. Hierdoor zijn bepaalde
			ontwerpbeslissingen en feiten over het programma niet
			beschikbaar die wel belangrijk zijn.

		\paragraph{Onbekendheid met de programmeertaal}

			Doordat de personen die het onderhoud moeten plegen onbekend
			zijn met de programmeertaal waarin de te onderhouden
			software geschreven is, kan de moeilijkheid toenemen.
			Wanneer een ontwikkelaar bekend is met de programmeertaal is
			hij ook bekend met de niet voor de hand liggende effecten van
			bepaalde code. 

		\paragraph{Complexiteit van het programma en de verandering}

			De complexiteit van het programma wat moet onderhouden
			worden speelt ook een grote rol bij de complexiteit van het
			onderhoud. Om het programma te onderhouden moet de kennis
			over wat het programma complex maakt ook aanwezig zijn bij
			de onderhouders. Daarbij is het vooral belangrijk dat hij
			ook de kennis heeft om de complexiteit van het programma
			kleiner te maken. 

		\paragraph{Het behoud van de integriteit van de architectuur en
		het lowlevel design.}

			Door onderhoud wordt de integriteit van de architectuur en
			design aangetast. Dit voorkomen voegt extra moeilijkheid
			toe. 

		\paragraph{Operationeel houden van het programma.}
	
			Een te onderhouden programma wordt veelal gebruikt in een
			operationele omgeving die vaak afhankelijk is van het
			programma.  Dit maak de deployment van de wijzigingen door
			onderhoud complexer, omdat het vaak wenselijk (en zelfs
			essentieel) is dat het programma met minimale downtime wordt
			gedeployed.

		\paragraph{slechte maintainabilty in het design}
			
			In de architectuur en het design van een programma kan
			rekening gehouden worden met mogelijk onderhoud. Als dit
			niet met het te onderhouden programma gedaan is, zal dit
			betekenen dat deze flexibiliteit alsnog in het design moet
			worden opgenomen. Het zou ook kunnen dat ervoor gekozen
			wordt het programma te wijzigen met dezelfde inflexibiliteit
			als hij al had. Dit zijn allebei tijdrovende en complexe
			scenario's. 

		\subsubsection{Maintaince activiteiten}

			De activiteiten die bij maintaince horen:

		\paragraph{Onderzoek naar het probleem en scope bepalen}
		
			Het uitvoeren van het onderhoud wordt met een bepaald doel
			gedaan. Met het onderhoud zullen waarschijnlijk een aantal
			problemen opgelost worden. Het onderhoud zal misschien
			meerdere onderdelen hebben die verschillende prioriteiten
			hebben. Ook zullen er grenzen en voorwaarden zijn aan het
			onderhoud. Dit is een van de activiteiten die bij het
			onderhoud hoort.
		
		\paragraph{Onderzoek van het te veranderen systeem.}

			Elk systeem heeft zijn eigenschappen, doel, ontwerp
			architectuur. De aanwezige informatie over het systeem zal
			moeten worden ge\"{i}nventariseerd en verzameld. Deze informatie
			zal helpen bij het uitvoeren van het onderhoud. Het kan zijn
			dat deze informatie op een leesbare en begrijpbare manier
			gedocumenteerd zijn. Dit is de ideale situatie. In het
			ergste geval zal deze informatie moeten komen uit een
			analyse op basis van de broncode.
		
		\paragraph{Identificeren invloed onderhoud.}

			Nu de informatie van het systeem beschikbaar is kan
			onderzocht worden welke invloed het onderhoud op het systeem
			heeft. Het is ook belangrijk om te onderzoeken op welke
			onderdelen het onderhoud invloed heeft. Zo komt men erachter
			welke delen van het systeem mogelijk ongewijzigd blijven.

		\paragraph{Herontwerp}

			De architectuur van het systeem moet mogelijk herontworpen
			worden op basis van de vorige stappen. Dit herontwerp zal de
			nieuwe situatie representeren en dicteren wat er
			uiteindelijk gewijzigt moet worden en hoe.

		\paragraph{Uitvoeren van de wijziging.}

			De daadwerkelijke wijziging in de code kan uitgevoerd worden
			op basis van de informatie die gewonnen is uit de vorige
			stappen.

		\paragraph{Testen en het maken van nieuwe tests}

			De tests die mogelijk aanwezig zijn om het programma te
			valideren, zijn na de wijziging mogelijk incorrect geworden.
			Daarom zullen er nieuwe tests geschreven moeten worden. Het
			is ook mogelijk dat er geen (of weinig) test aanwezig zijn.
			In dit geval moeten er nieuwe tests gecre\"{e}erd worden die de
			gewijzigde code valideert.

		\paragraph{Deployment plannen en uitvoeren}

			De wijziging zal in productie gezet worden. Dit zal bij
			deployment gebeuren en er moet een deployment scenario
			bedacht worden waardoor er minimale downtime optreed. Ook
			zal er rekening gehouden moeten worden dat er geen gegevens
			verlies optreed en dat de configuratie als invoer gebruikt
			wordt voor de nieuwe configuratie van het programma.

		\subsubsection{Benodigde kennis}

		De kennis die nodig is voor maintaince:

		\paragraph{Domeinkennis}

			Het programma waarover het onderhoud gevoerd wordt is vaak
			gebouwd op kennis van het domein van de ontwikkelaars. Deze
			kennis is daarom noodzakelijk voor het begrip van het
			programma. Omdat het uitvoeren van het onderhoud op basis
			van dit originele programma wordt gedaan is de domeinkennis
			ook belangrijk voor het onderhoud. Zonder deze kennis wordt
			kan de het onderhoud gebaseerd zijn op basis van verkeerde
			aannames. 

		\paragraph{Kennis gebruikte technieken en extra frameworks die
		gebruikt zijn}

			De meeste programma's maken gebruik van frameworks,
			technieken en externe programma's en tooling. Het onderhoud
			kan ook te maken hebben met de aansluitingen en gebruik van
			deze zaken. Kennis van deze zaken is daarom ook nodig voor
			het onderhoud.

		\paragraph{Kennis van de programmeertaal, compiler, IDE}

			Vaak is het gewenst om het onderhoud uit te voeren in
			dezelfde programmeertaal, compiler en IDE als het originele
			programma. Kennis van deze zaken is daarom van belang. Zelfs
			als er voor gekozen wordt de nieuwe delen of zelfs het
			volledige programma in een nieuwe programmeertaal of IDE te
			maken, is deze kennis belangrijk. Er moet immers bekend zijn
			wat het originele programma gedaan heeft. Kennis van de IDE
			is belangrijk om bestanden voor de project
			configuratie te identiviceren.

		\paragraph{Kennis van de architectuur en ontwerp}

			De architectuur en ontwerp van een programma geeft op een
			hogere abstractie niveau aan hoe applicatie is opgebouwd. Deze
			informatie is belangrijk om het te onderhouden programma
			goed te grijpen en snel te identificeren waar het onderhoud
			plaats dient te vinden. Ook kan het als een goed
			communicatie medium dienen voor discussies over het
			onderhoud en het programma zelf. 

		\paragraph{Kennis van de gebruikte deployment procedure}

			Na de het onderhoud van het programma zal de deployment
			opnieuw uitgevoerd moeten worden. Kennis van de voorheen
			gebruikte deployment procedure zal hierbij helpen. 
			Deze kennis is belangrijk omdat het een indicatie geeft van
			mogelijke pijnpunten in de deployment. Wanneer deze
			pijnpunten vermeden kunnen worden, zal de downtime van
			operationele systemen tot het minimale teruggebracht kunnen
			worden.
			
		\paragraph{Kennis van de aanwezige tests en testmethoden}

			Het is belangrijk te weten of en hoe er in het verleden
			getest is. Het is vaak gewenst om dezelfde testmethode te
			gebruiken voor nieuwe tests. Dit geldt ook voor het
			onderhoud. Kennis van wat er niet getest is geeft een
			indicatie welke onderdelen niet gevalideerd zijn. Hier zijn
			mogelijk onbekende defecten in het programma die van invloed
			zijn voor het onderhoud.
			
	\subsection{Opdracht 2.1}

		\begin{flushleft}
		\textbf{Aspect:} Revision history van het systeem.\linebreak
		\textbf{Fact:} Wie heeft er als laatst aan welk component
		gewerkt.\linebreak
		\textbf{Motivation:} Ontwikkelaars zijn de belangrijke bron van
		informatie over het systeem. Mocht de ontwikkelaar nog bereikbaar zijn
		of in het bedrijf werken, kan hij specifieke vragen beantwoorden die
		tijdens het onderhoud naar boven komen.\linebreak

		\textbf{Aspect:} Source Code\linebreak
		\textbf{Fact:} Lines of Code per component.\linebreak
		\textbf{Fact:} Aantal methoden met te hoge McCabe complexity\linebreak
		\textbf{Motivatie:} De grootte van een component geeft vaak een
		indicatie met betrekking tot de complexiteit. Wanneer een module veel
		functies heeft met een te hoge McCabe complexiteit, zal de module 
		complexer zijn. Hierdoor kan worden voorspeld in welke
		modules het meeste onderhoud zal worden gepleegd.\linebreak

		\textbf{Aspect:} Known Errors en Bugreports\linebreak
		\textbf{Fact:} Aan welke module zijn de meeste bugreports
		gelinked?\linebreak
		\textbf{Motivatie:} De kans dat een module meer onderhevig is aan
		onderhoud, wordt groter met het aantal bekende bugs die deze
		bevat. Ook hiermee kan worden voorspeld in welke modules het meeste
		onderhoud zal worden gepleegd.\linebreak

		\textbf{Aspect:} Documentatie\linebreak
		\textbf{Fact:} Het doel van het systeem\linebreak
		\textbf{Motivatie:} Op het moment dat het onbekend is wat het gewenste
		gedrag van een functie is, is het onmogelijk om hier bijvoorbeeld een
		bug in op te lossen. Dit is vooral een probleem bij corrective
		maintenance, omdat bij andere vormen van maintenance er altijd een
		bron is wat het systeem moet doen. Bij corrective maintenance is het
		daarom belangrijk om te weten wat het initi\"{e}ele doel was van het
		systeem, en of dit doel in de loop van de tijd is veranderd. Hierdoor
		kunnen design beslissingen uit het verleden worden verklaard. Ook kan
		er naar aanleiding van een eventuele verandering van het doel worden
		gekeken of de architectuur al voldoende is aangepast om dit nieuwe
		doel te dienen.
		\end{flushleft}

	\subsection{Opdracht 2.2}

		\subsubsection{Gebruikte methode}
	
			We hebben enkele aspecten welke belangrijk zijn voor onderhoud,
			zoals genoemd in opdracht 2.1, onderzocht voor JSPWiki. Hiervoor
			hebben we de volgende tooling gebruikt:

			\begin{itemize}

				\item LOC - Dit is een programma om het aantal regels code van
				een programma te tellen. LOC is te vinden op
				http://freshmeat.net/projects/loc/. Om het aantal regels code
				per module te vinden hebben we gebruik gemaakt van

				\begin{verbatim}
					find -maxdepth 1 -type d -print -exec
					~/Desktop/loc-1.1/loc {} \; | grep ^\.\/ -B 1 -A 1 | grep
					-v ^--
				\end{verbatim}

				\item PMD - PMD scant java code om te zoeken naar
				potenti\"{e}le problemen, waaronder de McCabe
				complexity. Hierbij geeft PMD een waarschuwing bij elke 
				methode met een McCabe complexity (Binnen PMD:
				CyclomaticComplexity) hoger dan 10. PMD is te vinden op
				http://pmd.sourceforge.net/.

				\item statsvn - Dit programma is gebruikt om het aantal
				changes per directory weer te geven. Statsvn is een tool
				die vanuit svn logfiles html pagina's met statistieken
				te genereren. Hij is te vinden op
				http://wiki.statsvn.org/.

				\begin{verbatim}
					svn log -v --xml > logfile.log
					java -jar statsvn.jar /<source directory>/logfile.log /<source directory>/
				\end{verbatim}
				
		\end{itemize}
		
		\subsubsection{Resultaten}

			Voor de resultaten hebben wij op basis van de change history
			aangenomen dat een aantal packages verplaatst zijn naar een
			nieuwe locatie en van naam zijn veranderd. De changes die
			vermeld zijn, representeren daarom niet 1 op 1 wat er in de
			change history staat, maar zijn een optelling van alle
			directories die vermoedelijk zijn verplaatst naar de
			desbetreffende directory die de module representeert.

			\begin{tabular}{ | l | l | l | l | l | }
				\hline
				Module & LOC & Complexity overtredingen & Changes & Totaal \\ 
				\hline
				Attachment & 873 & 4 & 211 & 1.85\% \\ 
				\hline
				Auth & 7090 & 34 & 1299 & 14.24\% \\ 
				\hline
				Content & 410 & 2 & 97 & 0.89\% \\ 
				\hline
				Dav & 1399 & 4 & 328 & 2.47\% \\ 
				\hline
				Diff & 612 & 0 & 76 & 0.56\% \\ 
				\hline
				Event & 773 & 8 & 131 & 2.37\% \\ 
				\hline
				Filters & 1245 & 7 & 183 & 2.58\% \\ 
				\hline
				Forms & 551 & 6 & 161 & 1.93\% \\ 
				\hline
				HtmlToWiki & 1214 & 7 & 93 & 2.32\% \\ 
				\hline
				I18n & 27 & 0 & 27 & 0.09\% \\ 
				\hline
				Management & 247 & 2 & 13 & 0.57\% \\ 
				\hline
				Modules & 4 & 0 & 35 & 0.1\% \\ 
				\hline
				Parser & 2954 & 11 & 250 & 4.53\% \\ 
				\hline
				Plugin & 3105 & 26 & 872 & 9.23\% \\ 
				\hline
				Preferences & 170 & 0 & 35 & 0.19\% \\ 
				\hline
				Providers & 2803 & 12 & 380 & 4.99\% \\ 
				\hline
				Render & 524 & 6 & 116 & 1.79\% \\ 
				\hline
				RPC & 352 & 0 & 68 & 0.39\% \\ 
				\hline
				RSS & 879 & 2 & 139 & 1.27\% \\ 
				\hline
				Search & 890 & 3 & 169 & 1.55\% \\ 
				\hline
				Tags & 4469 & 20 & 1173 & 9.64\% \\ 
				\hline
				UI & 2786 & 6 & 649 & 4.52\% \\ 
				\hline
				URL & 369 & 2 & 100 & 0.87\% \\ 
				\hline
				Util & 1611 & 8 & 261 & 3.2\% \\ 
				\hline
				Webdocs & 15124 & 0 & 4401 & 20.52\% \\ 
				\hline
				Wikipages & 5447 & 0 & 795 & 5.27\% \\ 
				\hline
				Workflow & 1090 & 0 & 204 & 1.18\% \\ 
				\hline
				Xmlrpc & 802 & 0 & 161 & 0.89\% \\
				\hline
			\end{tabular}

			In de tabel worden de volgende gegevens weergegeven:

				\paragraph{ Module } 
	
				- De module welke op complexiteit wordt
				gecontroleerd.

				\paragraph{ LOC } 

				- Aantal regels code in de module. Hierbij wordt van
				alle java bestanden het aantal regels geteld waar code
				staat. Lege regels en commentaar wordt gefilterd.

				\paragraph{ Complexity overtredingen } 

				- Het aantal functies in de module met een McCabe
				Complexity hoger dan 10.

				\paragraph{ Changes } 

				- Het aantal changelogs waar ten minste een bestand van
				die module is gewijzigd.

				\paragraph{ Totaal } 

				- Optelsom waarbij LOC, Complexity overtredingen en
				changes worden meegerekend. Aangenomen dat meer regels
				code, meer complexity overtredingen en meer changes
				betekend dat een module complexer is, zegt deze score
				iets over de complexiteit van een module. 

			De modules met de hoogste score is webdocs. In webdocs staat de
			front-end van de applicatie. Wij nemen aan dat eventuele
			wijzigingen in de front-end ook implicaties zullen hebben in de
			back-end, waarbij de complexiteit van de wijzigingen in de
			back-end een stuk hoger zal liggen. Vandaar dat we denken dat
			hier weinig maintenance risico ligt. In deze hebben we de
			front-end gedefinieerd als de .jsp bestanden en de back-end
			de ondersteunende classes en interfaces. 

			De volgende module welke opvalt met een hoge score is auth. Bij
			het bekijken van de documentatie bleek ook dat dit de enige module
			is waar een diagram van is gemaakt. Dit betekend dat dit een
			complexe module is en dus extra aandacht verdient tijdens het
			inlezen in het programma.

			Het is ook belangrijk om naar de plugin en tags modules te
			kijken, dit omdat deze na webdocs en auth de meeste
			complexiteit bevatten.

		\subsubsection{Voordelen:}

		\paragraph{De applicatie is uitbreidbaar gemaakt.}
				
			De applicatie heeft een plugin feature die het doel heeft
			de uitbreidbaarheid (vooral door 3de partijen) te
			vereenvoudigen. Ook kan de gebruiker er voor kiezen bepaalde
			plugins wel of niet te gebruiken. JSPWiki maakt zelf ook
			gebruik van het plugin systeem, met zijn core-plugins. Dit
			is een groot voordeel, omdat er op dit punt heel actief is
			nagedacht over uitbreidbaarheid en modularisatie. Dit helpt
			bij onderhoud waarbij de architectuur niet aangetast hoeft
			te worden, in het bijzonder bij het uitbrengen van
			nieuwe features.
			
		\paragraph{Javadoc Comments zijn goed beschrijvend.}
				
			Doordat de Javadocs comments in de broncode goed
			beschrijvend zijn, zijn de doelen van verschillende classes,
			packages en methoden voor de onderhoudende partij snel
			duidelijk. Het help snel de ontwerpbeslissingen te
			identificeren en de structuur en ontwerp te achterhalen.
			
		\subsubsection{Nadelen:}

		\paragraph{Een aantal modules overstijgen in complexiteit en
		omvang.}

			Van een aantal modules worden veel
			complexiteits-overtredeing gemaakt. Dit verminderd de
			leesbaarheid en daardoor zullen deze modules minder snel
			begrepen worden. De grote omvang van sommige modules
			degradeert het overzicht en de leesbaarheid.

		\paragraph{Geen architecture of high-level design} 

			De afwezigheid van een high-level design of architectuur
			forceert dat deze bij onderhoud door analyse gereproduceerd
			moet worden. Hierbij is de kans aanwezig dat veel
			ontwerpbeslissingen onbekend zullen blijven.

	\subsection{Opdracht 2.3}

		Systematisch stappenplan:

			\paragraph{Onderzoeken wat het programma moet doen.}
			
				Het is lastig om een defect te repareren of een feature
				toe te voegen als het onbekend is wat het programma moet
				doen.  Het is onmogelijk om deze taak te automatiseren,
				omdat het doel van een programma vaak in de documentatie
				zal zijn beschreven.

			\paragraph{De architectuur van het programma bekijken en/of
			reproduceren.}
			
				Het is belangrijk om de architectuur te begrijpen, omdat
				de ontwerpbeslissingen en structuur van het programma
				die hier in staat helpt bij het identificeren waar de
				wijzigingen plaats moeten vinden.  In het geval dat er
				geen architectuur ontwerp beschikbaar is, is het
				productief om een tool te hebben die op basis van de
				huidige broncode de architectuur reproduceert. Omdat
				echter in architectuur ook informatie staat die niet in
				de broncode aanwezig is, is de mogelijkheid dat zo een
				tool alle informatie geeft die een architectuur ook
				bevat nihil. In het geval dat er wel een ontwerp
				aanwezig is heeft deze tool ook nut, want dan kunnen
				verschillen tussen het ontwerp en de huidige situatie
				onderzocht worden.

			\paragraph{Onderzoeken wat het doel van iedere module van het programma
			is.}
			
				Dit vergroot het begrip van de architectuur. Daarnaast
				is het hierna makkelijker om te bepalen waar een
				bepaalde wijziging plaats moet vinden.

			\paragraph{Standaard features}
			
				In deze stap dient men er achter te komen hoe standaard
				features als logging, errorhandling, authorisatie en
				database toegang zijn verspreid door de code. Hierbij
				kan tooling nuttig zijn welke alle aanroepen naar een
				bepaalde class of functie zoekt.

			\paragraph{Het uitvoeren van de unit tests.}
			
				Hierbij kan de code coverage worden bepaald. Daarnaast
				kan er worden gekeken of er testen zijn welke falen, nog
				voordat er wijzigingen in de code zijn doorgevoerd.

			\paragraph{Het ontdekken van de pijnpunten in de code}
			
				Op deze manier kan worden voorspelt welke modules
				waarschijnlijk het meeste onderhoud nodig gaan hebben.
				Hiervoor kunnen verschillende metrieke worden gebruikt:

			\begin{itemize}

				\item Het aantal regels code per module.

				\item Het aantal bugreports per module.

				\item Het aantal changes gemaakt in een module.

				\item De testcoverage van een module.

				\item De McCabe complexity van de code worden gebruikt.

			\end{itemize}

\section{Opdracht 3: Prepare for series 2 and 3}

	\subsection{Opdracht 3.2}

	\begin{figure}[hb]
		\centering
		\includegraphics[width=\textwidth]{parsetreeformula}
		\caption{De parsetree van de formule 9 - 5 \^{ } 2 * 7 + 4.}
		\label{fig:parsetreeformula}
	\end{figure}

	De lexical syntax definieert de elementen van een taal. Het geeft
	aan op welke manier de elementen opgebouwd kunnen zijn. De
	context-free syntax beschrijft vervolgens de regels over hoe deze
	elementen gebruikt kunnen worden. In afbeelding
	\ref{fig:parsetreeformula} wordt de parsetree van de formule 9 - 5
	\^{ } 2 * 7 + 4 gegeven. In de parsetree  wordt de onderste rij met
	nodes geparsed door de lexical syntax en de rest met de context-free
	syntax.

	Het artikel over syntax analysis is helder genoeg om het compleet te
	begrijpen. We hebben niet het idee dat we iets niet begrijpen uit
	het artikel. Dit kan ook betekenen dat we onbewust onbekwaam zijn,
	maar we vermoeden dat dit niet het geval is. Dit vermoeden berusten
	we op het feit dat we heel zeker zijn van de correctheid van de
	parse tree en tijdens construction al veel hebben gedaan met
	parsing.

	\subsection{Opdracht 3.3}

	\begin{figure}[hb]
		\centering
		\includegraphics[width=\textwidth]{parsetreeformula2}
		\caption{De parsetree van de formule 9 - 5 \^{ } 2 * 7 + 4 met
		omgekeerde prioriteit.}
		\label{fig:parsetreeformula2}
	\end{figure}

	Wanneer we rekenregels van de formule omkeren krijgen we de
	parsetree die in afbeelding \ref{fig:parsetreeformula2} gegeven is.
	Een redex is het deel van de volledige term waarvoor een match
	gezocht word in de rules. De redexen van de formule met omgekeerde
	regels (zoals aangegeven in afbeelding \ref{fig:parsetreeformula2})
	zijn opeenvolgend:
	
	\begin{center}
	\begin{tabular}{| l | l | l | l |}
		
		\hline
			Redex & Resultaat & Rule & Resulterende expressie\\
			
		\hline

			9 - 5 & 4 & 9 - 5 = 4 & \textbf{4} \^{ } 2 * 7 + 4\\

		\hline

			7 + 4 & 11 & 7 + 4 = 11 & 4 \^{ } 2 * \textbf{11}\\

		\hline

			2 * 11 & 22 & 2 * 11 = 22 & 4 \^{ } \textbf{22}\\

		\hline

			4 \^{ } 22 & 1.7592186*$10^{13}$ & 4 \^{ } 22 =
			1.7592186*$10^{13}$ & \\

		\hline

	\end{tabular}
	\end{center}

	De tabel geeft op elke rij en stap in de parsing van de formule met
	omgekeerde regels. De kolom redex geeft aan welke redex in de stap
	geparsed moet worden. De kolom resultaat geeft de uitkomst van de
	geparsete redex. De kolom Rule geeft aan welke parsing regel er
	gebruikt is om de oplossing te krijgen. De kolom Resulterende
	expressie geeft de expressie die gebruikt word om de volgende
	parsing stap uit te voeren.
	
	Het artikel over term rewriting is door ons beiden direct begrepen.
	We hebben hierbij alle informatie die nodig is om zelf een rewriting
	uit te voeren.

\bibliography{bibliography}

\bibliographystyle{plain}

\end{document}


% vim: textwidth=72:shiftwidth=4:tabstop=4:smartindent
